MVC pattern

Probleem

De vraag die echter weinig gesteld wordt is welk probleem lost MVC nu eigenlijk op? De meest courante antwoorden zijn herbruikbaarheid van de code, schaalbaarheid. Het zijn allemaal voordelen voor de programmeur of vanuit het standpunt van de programmeur. Maar waarom zou je dan MVC gebruiken en geen ander patroon zoals bijvoorbeeld data-driven?

Nochtans begint Trygve zijn paper met het uiteenzetten van het probleem dat hij wou oplossen:

MVC was conceived as a general solution to the problem of users controlling a large and complex data set.

en even voordien:

The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly. The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints. The figure below illustrates the idea.

Van MVC Xerox Parc 1978-79

Design

De naam van het patroon verwijst naar de drie hoofdbestandelen: Model, View, en Controller. Een volledige en juiste visuele voorstelling ziet er uit als het volgende diagram:

Omschrijving

Model

1. definieert de voorstelling van de informatie in de applicatie
2. Is de voorstelling (representation) van de onderliggende logische structuur van de gegevens in een applicatie en is de een klasse die ermee verbonden is
3. Het object model bevat geen enkele informatie over de gebruikersinterface

View

1. weergave van de Informatie met behulp van userinterface-elementen

Controller

1. De controller verwerkt en reageert op events, die het gevolg zijn van handelingen van een actor.
2. De controller is de koppeling tussen de gebruikersinterface (view) en de verwerkingslogica (model). De controller gebruikt de modelmethoden voor het ophalen van informatie over het applicatie-object (ding, entiteit) of voor het wijzigen van de status van het object. De controller informeert vervolgens de view over de wijzigingen. De controller laat in zekere zin de gebruiker toe wijzigingen aan te brengen en de resultaten daarvan te zien.

Vereisten

1. De controller en de view zijn afhankelijk van het model. Het model is niet afhankelijk van de view of van de controller. Dat is de reden waarom de M eerst komt. Het model moet getest kunnen worden en gebruikt op zichzelf.
2. De controller is afhankelijk van de view en het model.
3. De view ontvangt geen gegevens van de controller. Er is geen direct verband tussen de view en de controller, het model staat er altijd tussenin.

MVC is een ontwerppatroon dat programmeurs gebruiken om de drie taken in een app, namelijk presenteren van informatie (view), verwerken van interactie (controller), beheren van van de info (model) in afzonderdelijke delen onder te brengen. Elk onderdeel heeft een eigen, specifieke verantwoordelijkheid. Die onderdelen zijn onderling met elkaar verbonden. Het model kan de implementatie bevatten om gegevens uit de database te halen of ernaar weg te schrijven. MVC veralgemeent (maakt een patroon) hoe de informatiestroom in een applicatie wordt geïmplementeerd:

1. model waarop we willen bouwen;
2. view is gebruikersinterface van de toepassing;
3. controller beheert de logica van de applicatie, wat de doen als...;